Support loading binary files in addition to ELF files #175
Conversation
QEMU embeds the location of the kernel image in the device tree. Store this address in the environment as variable kernel_start and use it in CONFIG_BOOTCOMMAND to boot the kernel. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de> Series-to: u-boot Series-cc: bmeng Cover-letter: General fixes / cleanup for RISC-V and improvements to qemu-riscv This patch series includes general fixes and cleanup for RISC-V. It also adds support for booting Linux on qemu-riscv. At the moment, only single-core systems are supported. Support for multi-core systems will be added with a future patch series. To boot Linux on qemu-riscv, Linux must be compiled into BBL as a payload. BBL must be included in a FIT image and supplied to QEMU with the -kernel parameter. Its location in memory is embedded in the device tree, which QEMU passes to u-boot. To test this, QEMU and riscv-pk (BBL) must be modified. QEMU is modified to add support for loading binary files (FIT images in this case) in addition to ELF files. riscv-pk must be modified to adjust the link address and to ignore the kernel address from the device tree. A pull request for QEMU, which implements this, is available at [1]. A modified version of riscv-pk is available at [2]. [1]: riscvarchive/riscv-qemu#175 [2]: https://github.com/lukasauer/riscv-pk/tree/riscv-u-boot END
|
Ping? |
hw/riscv/boot.c
Outdated
| @@ -46,15 +46,25 @@ static uint64_t kernel_translate(void *opaque, uint64_t addr) | |||
| } | |||
| } | |||
|
|
|||
| hwaddr riscv_load_firmware(const char *filename) | |||
| hwaddr riscv_load_firmware(const char *filename, hwaddr ram_start, | |||
| uint64_t ram_size) | |||
There was a problem hiding this comment.
We should avoid requiring "ram_size", It possible there may be configurations with discontiguous memories and this is incompatible with that. We spent a bit of effort to removing hardcoding of assumptions with respect to memory from core code. Hopefully, it doesn't creep back in.
There was a problem hiding this comment.
I was not aware of that. I will update the patch to remove ram_size.
hw/riscv/boot.c
Outdated
| firmware_entry = ram_start; | ||
| firmware_start = ram_start; | ||
|
|
||
| size = load_image_targphys(filename, firmware_start, ram_size); |
There was a problem hiding this comment.
As far as I can tell, the size on load_image_targphys is the maximum firmware size so we could perhaps add a constant for maximum firmware size. This simplifies the patch as the we no longer have to make assumptions about memory type, however it would add a maximum limit on the firmware size. I think the latter is reasonable. There is a firmware size limit on the HiFive Unleashed iirc. Perhaps some suitable value base on the size of a reasonable kernel and ramdisk.
There was a problem hiding this comment.
QEMU ROM routines won't overwrite past the end of the memory regions so it doesn't matter too much what the limit is.
There was a problem hiding this comment.
That makes sense. Since we won't have a problem with overwriting past memory regions, how about 2 GB to fill the complete address range of RV32I systems?
hw/riscv/boot.c
Outdated
| @@ -71,15 +81,31 @@ hwaddr riscv_load_firmware(const char *filename) | |||
| return firmware_entry; | |||
| } | |||
|
|
|||
| hwaddr riscv_load_kernel(const char *filename, void *fdt) | |||
| hwaddr riscv_load_kernel(const char *filename, void *fdt, hwaddr ram_start, | |||
| uint64_t ram_size) | |||
| void riscv_load_initrd(const char *filename, uint64_t mem_size, | ||
| hwaddr firmware_entry, void *fdt); | ||
| hwaddr riscv_load_firmware_kernel_initrd(MachineState *machine, void *fdt); | ||
| hwaddr riscv_load_firmware_kernel_initrd(MachineState *machine, void *fdt, | ||
| hwaddr ram_start); |
There was a problem hiding this comment.
The bulk of the patch seems to be plumbing through ram_size. The actual change is pretty small after this unnecessary plumbing is removed.
There was a problem hiding this comment.
Thanks for your review!
That's true, but I will still need to add ram_start here.
michaeljclark
force-pushed
the
qemu-for-testing
branch
from
1431b8b to
3cc4afd
Compare
The kernel and bootloader are not always available as ELF files, or directly executable. For example, the kernel might be included together with a device tree inside of an image. Support this use case by allowing binary files to be loaded in addition to ELF files. With this patch, the files specified with the -bios and -kernel parameters are attempted to be loaded as ELF files first. If this fails, they are loaded directly to memory instead. The binary size is limited to 2 GiB to stay within the 32-bit address space and ensure compatibility with both RV32I and RV64I. Signed-off-by: Lukas Auer <lukas.auer@aisec.fraunhofer.de>
lukasauer
force-pushed
the
riscv-load-binaries
branch
from
feaccdf to
b375928
Compare
|
I have updated my patch with your comments. Please let me know if it looks good to you now. |
The kernel and bootloader are not always available as ELF files, or
directly executable. For example, the kernel might be included together
with a device tree inside of an image. Support this use case by adding
support for loading binary files in addition to ELF files.
With this patch, the files specified with the -bios and -kernel
parameters are attempted to be loaded as ELF files first. If this fails,
they are loaded directly to memory instead.